The invention relates generally to computer-based directory services, and more particularly to a system and method for using schema attributes as meta-data in a directory service.
Computer systems generally comprise two or more computers networked together to enable the sharing of applications, services, and information. Most computer systems store and maintain data (in various formats) relating to the many network resources that comprise the system. Examples of such resources may include, but are not limited to computers and various peripheral devices (e.g.xe2x80x94printers, RAID devices, etc.), as well as users, files, and e-mail addresses. Directory services are a valuable tool utilized by computer systems to aid in storing and maintaining this data.
A directory service typically identifies all of the resources on a network and makes them accessible to users and applications. Currently, many computer systems utilize distributed directories. A distributed directory is a single directory that spans (and is shared by) multiple networking servers. Most distributed directories are based on the X.500 ITU (International Telecommunication Union) standard which structures directories in a hierarchical fashion, having different levels for different categories of information. Many directory service providers utilize hierarchical databases, which may be referred to as either xe2x80x9cdirectory service databasesxe2x80x9d or xe2x80x9cdirectory service repositories.xe2x80x9d Distributed directories based on the X.500 standard allow for information to be created, read, and modified by clients having the appropriate access rights. This information may be shared across a plurality of servers and clients.
One example of a well-known directory service or system that uses a distributed directory with a hierarchical database structure is NetWare Directory Services(trademark) (xe2x80x9cNDSxe2x80x9d) by Novell Corporation. The structure of at least one NDS directory system may be understood by defining terms such as meta-data, schema, and instance.
Traditionally, meta-data in a directory system may describe the syntax or format of data so that the system may understand how data is being represented in the system. Meta-data may also specify that a directory system may have attributes, and that these attributes may be grouped into entities known as classes. Generally, meta-data defines the model for schemas in a directory system.
A schema typically defines a set of attributes that are defined together to define or describe a class. NDS allows network administrators to create classes in the schema using attributes defined by the administrators. Each attribute in a class has certain information associated with it, such as an attribute name and an attribute syntax type. The attribute name identifies the attribute, while the attribute syntax limits the values that are assumed by the attribute. In addition to defining attributes or properties, classes may also contain other meta-data describing the behavior of the class.
Once a network administrator has created a class, users having appropriate access rights may then create objects based on that class. These objects, also referred to as instances of the class, are then entered into the distributed directory. Multiple instances of the same class may exist in a directory as long as each possesses a unique name. Although objects in a distributed directory tend to represent computer-related entities (e.g.xe2x80x94computers, printers, users), those skilled in the art understand that objects may also represent a variety of non-computer-related entities such as companies, departments, buildings, or the like.
One feature of directory service hierarchical databases allows for classes to be derived from (or based upon the declaration of) other classes. This concept, known as inheritance, is explained with reference to FIG. 1. FIG. 1 illustrates a portion of a distributed directory 100 wherein each block illustrated represents a class. For ease of explanation, assume that a help desk policy class 110 exists in distributed directory 100, and is derived from (or based on the declaration of) a general policy class 120, a WINDOWS 98(trademark) type policy class 130, a user type policy class 140, and a scheduled feature policy class 150. Because help desk policy class 110 is derived from policy classes (120, 130, 140, 150), any instances (or objects) of the help desk policy class 110 created in directory 100 must contain all of the mandatory attributes defined by its own class definition (which may be none), as well as all of the mandatory attributes defined in the class definitions of policy classes (120, 130, 140, 150). This is because valid instances or objects of a derived class must include the mandatory attributes of the base class or classes from which it is derived. Help desk policy class 110 may be referred to as a derived class or subclass because it inherits the characteristics of policy classes (120, 130, 140, 150). In turn, policy classes (120, 130, 140, 150) are referred to as base classes or super classes because their characteristics are inherited by another class, namely help desk policy class 110. It should be recognized that FIG. 1 is an illustration of multiple inheritance, as the derived help desk policy class 110 is inheriting the characteristics of more than one base class.
Through the derivation described above, the directory system may now make a determination that help desk policy class 110 is a policy class that is acceptable for WINDOWS 98(trademark) systems, and for users, and that it is a policy class that may be scheduled. Such a determination may be made by examining the names of the base policy classes (120, 130, 140, 150) that help desk policy class 110 is derived from. Since the names of the base policy classes (120, 130, 140, 150) are well known and constant, and because help desk policy class 110 is derived from these base policy classes, the system is able to make this determination about the help desk policy class 110 and any eventual instances of the help desk policy class 110 that may be created.
Those skilled in the art will realize that policy classes (110, 120, 130, 140, 150) are but a few representative examples of policy classes that may be created to manage resources of a computer system such as users, workstations, or servers. These policy classes may also apply to various operating systems and may be capable of supporting various features.
One drawback associated with using hierarchical database structures is that derivation is generally a one-time process. In other words, when an administrator or other individual creates a new subclass that is to be derived from a base class, he or she may be limited in the future to only those attributes that were included in the class definition of the new subclass at the time of creation.
In FIG. 1, for example, help desk policy class 110 was derived from policy classes (110, 120, 130, 140, 150) and was defined to include any new attributes along with the attributes that were inherited from policy classes (110, 120, 130, 140, 150). If a network administrator, in the course of organizing or managing objects or instances of classes, later discovers that help desk policy class 110 shares the structure and behavior of some other existing base class (not shown), it may be disadvantageous for the help desk policy class 110 to derive from this newly discovered base class. If the help desk policy class 110 is allowed to derive from the newly discovered base class, any subsequent objects or instances of the help desk policy class 110 created would conflict with objects or instances of the help desk policy class 110 already in existence. The network administrator would most likely be forced to create a new help desk policy class and re-create all of the old objects already in existence.
The inability to modify a class schema by adding attributes later may result in an inflexible and inefficient system. These and other drawbacks exist. For this reason, it may be valuable for network administrators managing classes in a directory to be able to determine the user interface and behavior of a class before any objects or instances of the class are created in the directory. In addition, it may valuable for network administrators to understand how different classes relate to one another before any objects or instances of the classes are created in the directory.
The invention solving these and other problems in the art relates to a system and method for using schema attributes as meta-data in a directory service.
According to an embodiment of the invention, a directory service may be used with a computer system or network to aid in storing and managing data or other information relating to the system. Prior to creating an object class in a directory service, various data or other information pertaining to one or more network resources in a computer system may be identified. A group of attributes that will be used to describe this data may be given special names or menacingly the individual creating the class. These attributes may then be included in the class schema. After a class has been created, users having appropriate access rights may then create objects or instances of the class in the directory.
One advantage of this embodiment is that the user interface and behavior of a class may be determined before any objects or instances of the class ever exist in the directory. This may be accomplished by reading the class schema and identifying the attributes which exist in the schema that have been given special meaning.
Another advantage of this embodiment is that additional attributes may be added to the class schema if the meaning or use of the class has changed, or if any additional attributes are needed to describe how the class should behave.
According to one embodiment of the invention, a directory system may define or determine relationships between various classes in the directory via a specially named relationship class. First, at least two classes in a directory that share some type of relationship may be identified. A name that appropriately identifies the relationship between the at least two classes may be selected, and then a relationship class having the selected name may be created in the distributed directory. The relationship class may have an attribute that is specially named to indicate that its multiple values may include the names of the classes participating in the relationship. When the relationship class is created, however, no values may be assigned to the attribute. Rather, values for the attribute may be assigned in an object or instance of the relationship class, after the object or instance of the relationship class is created in the directory. Once an object or instance of the relationship class is created in the directory, the directory system may search the directory tree to locate the instance of the relationship class. Upon finding this object in the tree, the directory system may read the value of the attribute to discover the names of the classes that participate in the relationship.
One advantage of this embodiment is that more than one object or instance of the relationship class may be created in the directory, allowing for customization in different segments of the directory tree. Customization may be advantageous because, for example, relationships between classes may be different for different subtrees of the directory.
Another advantage of this embodiment is that the values of the attribute in the instance of the relationship class may be modified if the relationship between classes (identified by the relationship class and its object) has changed.
According to one embodiment of the invention, a directory system may define or determine several relationships between various classes in the directory via a general relationship class. First, various relationships between classes in a directory may be identified. Names that appropriately identify these relationships between classes may be selected. Next, a general relationship class may be created in the directory, having a first attribute and a second attribute. When the general relationship class is created, however, neither of the attributes may be assigned any values. Rather, values for these attributes may be assigned in an object or instance of the general relationship class once the object or instance is created in the directory. Various value fields for the first attribute may include the names that were created to define the various types of relationships that may exist between classes in a directory. The names of classes that participate in the relationships named in the value fields of the first attribute may then be assigned to corresponding value fields in the second attribute. Once an object or instance of the general relationship class is created in the directory, the directory system may search the directory tree to locate an instance of the general relationship class. Upon finding this object in the tree, the directory system may read the value fields of the first attribute to discover the various relationships that are represented. Next, the directory system may read the corresponding value fields for the second attribute to find the names of the classes that are participating in the respective relationships.
One advantage of this embodiment is that more than one object or instance of the general relationship class may be created in the directory, allowing for customization in different segments of the directory tree. Customization may be advantageous because, for example, relationships between classes may be different for different subtrees of the directory.
Another advantage of this embodiment is that the values of the attribute in the instance of the general relationship class may be modified if the various types of relationships between the classes have changed, as well as whether the names of any classes participating in the relationships have changed.